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Extensible Markup Language (XML) Format Extension for Representing 
Copy Control Attributes in Resource Lists 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


In certain types of multimedia communications, a Session Initiation 
Protocol (SIP) request is distributed to a group of SIP User Agents 
(UAs). The sender sends a single SIP request to a server which 
further distributes the request to the group. This SIP request 
contains a list of Uniform Resource Identifiers (URIs), which 
identify the recipients of the SIP request. This URI list is 
expressed as a resource list XML document. This specification 
defines an XML extension to the XML resource list format that allows 
the sender of the request to qualify a recipient with a copy control 
level similar to the copy control level of existing email systems. 
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1. Introduction 


RFC 5363 [RFC5363] describes a generic framework for carrying Uniform 
Resource Identifier (URI) lists in SIP [RFC3261] messages. 
Specifically, the document provides a common framework for specific 
implementations of URI-list services, such as conferences initiated 
with INVITE requests [RFC5366] or Multiple-recipient MESSAGE requests 
[RFC5365]. 


Common to all URI-list services is the presence of a SIP request that 
contains a collection of resources, typically expressed as an XML 
resource list [RFC4826]. SIP requests carrying resource lists can 
appear either in requests received by the URI-list server, indicating 
the list of intended recipients, or in each of the requests that the 
URI-list server sends to recipients, indicating the list of 
recipients of the same SIP request. 


Although the XML resource list [RFC4826] provides a powerful 
mechanism for describing a list of resources, there is a need for a 
copy control attribute to determine whether a resource is receiving a 
SIP request as a primary recipient, a carbon copy, or a blind carbon 
copy. This is similar to common email systems, where the sender can 
categorize each recipient as a "to", "cc", or "bcc" recipient. 


This document addresses this problem by providing an extension to the 
XML resource list [RFC4826] that enables the sender to supply a copy 
control attribute that labels each recipient as a "to", "cc", or 
"bcc" recipient. This attribute indicates whether the recipient is 
receiving a primary copy of the SIP request, a carbon copy, ora 
blind carbon copy. Additionally, we provide the sender with the 
capability of indicating in the URI list that one or more resources 
should be anonymized, so that some recipients’ URIs are not disclosed 
to the other recipients. Instead, these URIs are replaced with 
anonymous URIs. 


The remainder of this document is organized as follows: Section 2 
introduces the terminology used throughout this specification. 
Section 3 gives an overview of operation. Section 4 formally defines 
an extension to URI lists. The XML schema definition is provided in 
Section 5. Section 6 shows examples of the URI lists with the 
extensions defined in this document. Section 7 discusses the 
implications of carrying URI lists in SIP messages. 
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2's 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119] and indicate requirement levels for compliant 
implementations. 


URI-list service: SIP application service that receives a SIP 
request containing a URI list and sends a similar SIP request to 
each URI in the list. 


Intended recipient: The intended final recipient of the request to 
be generated by URI-list service. 


Copy control: An attribute assigned by the sender to a URI in an 
XML resource list. Its purpose is to indicate to the recipient 
whether he is getting a primary, carbon, or blind carbon copy of 
the SIP request. 


Recipient list or recipient XML resource list: An XML resource list 
containing the list of intended recipients. The sender sets this 
list in the SIP request he sends to the URI-list server. 


Recipient-history list or recipient-history XML resource list: An 
XML resource list containing the visible list of recipients (i.e., 
those non-anonymous non-bcc). The URI-list server creates this 


list, based on the recipient list, and includes it in each of the 
SIP requests it sends to each recipient. 


Overview of Operation 


Figure 1 depicts a general overview of the operation of a URI-list 
server. A SIP User Agent Client (UAC) issuer sends a SIP request 
(F1) to a URI-list server containing a recipient list. The URI-list 
server generates a SIP request to each recipient, according to the 
specific SIP method. Each of these SIP requests contains a 
recipient-history list that indicates the visible list of recipients 
of the SIP request. 
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+-------- + +--------- + +-------- + 4+-------- + 4+-------- + 
|SIP UAC | | URI-list | |intended| |intended| |intended| 
issuer server recip. recip. recip. 

1 2 3 
+-------- + +--------- + +-------- + 4+-------- + 4+-------- + 


| | 
| F1 SIP request | 
| (recipt. list) | 


[entanti 29522 | F3 SIP request 
| (recp-hist.list) 
| --------------- > 
| F4 SIP request 
| (recp-hist.list) 


F5 SIP request | 
| (recp-hist.list) | | 


Figure 1: Example of operation 


The URI-list mechanism allows a sender to specify multiple targets 
for a SIP request by including a recipient XML resource list 
[RFC4826] in the body of the SIP request. This recipient list 
includes the target URIs of the SIP request (the actual procedures 
are method specific and outside the scope of this document). Each 
target URI may also be marked with a copy control attribute to 
indicate the copy level in which the recipient is receiving the SIP 
request. This is achieved by the sender qualifying each URI in the 
URI list with a ’copyControl’ attribute. The available values of the 
"copyControl” attribute include "to", "cc", and "bcc" (analogous to 
email). This is discussed in greater detail in Section 4. When the 
URI-list server expands the request to each recipient, the URI-list 
server includes a recipient-history XML resource list built upon the 
recipient list received from the sender. The recipient-history XML 
resource list replaces the recipient list in the SIP requests 
generated by the URI-list server towards each recipient. The URI- 
list server copies from the recipient list those targets that are 
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marked with the "to" and "cc" copy control level, and pastes them in 
the recipient-history list. The URI-list server explicitly excludes 
from the recipient-history list those URIs marked with a "bcc" copy 
control, although it is able to preserve the address of a "bcc" 
tagged URI when it matches the URI of the recipient of the SIP 
request (this is described later in Section 4). When a recipient 
receives the SIP request containing the recipient-history XML 
resource list, he is able to determine which other visible recipients 
are getting a copy of the SIP request, and whether they are marked 
with the "to" or "cc" copy control level. Later, if needed, the 
recipient can generate a reply to those visible recipients. 


In addition to the ’copyControl’ attribute for a URI in an XML 
resource list, we define a second boolean attribute called 
‘anonymize’. The sender of a SIP request can mark a URI ina 
recipient XML resource list with the 'anonymize” attribute to 
indicate the URI-list server that the URI marked with that attribute 
is to be replaced with an anonymous URI in the recipient-history XML 
resource list. This provides knowledge to the recipients of a SIP 
request of the number of additional visible recipients whose URIs 
have not been disclosed. 


There are cases when the sender marks several URIs with the 
‘anonymize’ attribute. The URI-list server can group the anonymized 
URIs in a single anonymized URI within its copy control level, and 
provide a count of the number of anonymized URIs. To support this 
scenario, we define a new ‘count’ attribute to a URI in the 
recipient-history XML resource list. It is expected that the ’count’ 
attribute is only used with anonymous URIs, although syntactically it 
is possible to add a ’count’ attribute to any URI in any XML resource 
list. 


Initially, it may be thought that the 'anonymize” attribute overlaps 
with the "bcc" value of the 'copyControl” attribute. However, there 
are differences between them. If the sender qualifies a URI with a 
"copyControl” attribute of "bcc" in the recipient XML resource list, 
the URI-list server will typically remove that URI from the 
recipient-history XML resource list (unless the URI-list server 
decides to preserve a "bcc" marked URI when that URI is itself the 
recipient of the SIP request). Recipients of the SIP request will 
not notice that one or more extra "bcc" URIs also received the 
request. However, if the sender qualifies a URI with the ’anonymize’ 
attribute in the recipient XML resource list, the URI-list server 
will replace the URI with an anonymous one in the recipient-history 
list. Recipients of the SIP request will notice that there have been 
one or more additional recipients of the same request, but their URIs 
are not disclosed. 
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4. 


Extension to the Resource List Data Format 


This document defines an extension to the XML resource list data 
format [RFC4826] that allows the sender to indicate a copy control 
attribute that qualifies a recipient with a copy control level. We 
define a new ’copyControl’ attribute to the <entry> element of the 


resource list document format [RFC4826]. The 'copyControl” attribute 
has similar semantics to the type of destination address in email 
systems. It can take the values "to", "cc", and "bec". A "to" value 


of the ’copyControl’ attribute indicates that the resource is 
considered a primary recipient of the SIP request. A "cc" value 
indicates that the resource receives a carbon copy of the SIP 
request. A "bcc" value indicates that the resource receives a blind 
carbon copy of the SIP request (i.e., this URI is not disclosed to 
other recipients of the SIP request). The default ’copyControl’ 
value is "bcc". That is, the absence of a ’copyControl’ attribute 
MUST be treated as if the ’copyControl’ was set to "bcc". 


When creating a recipient-history list, URI-list servers use "bcc" 
"copyControl” attributes to route SIP requests. In addition, URI- 
list servers behave similarly to email systems [RFC2822] with respect 
to the treatment of these URIs marked with a "bcc" copy control, 
because they have two ways of treating "bcc" marked URIs. URI-list 
servers MUST treat these "bcc" marked URIs in either of the following 
two ways: 


o URI-list servers MUST remove all URIs marked with a "bcc" copy 


control in recipient-history lists. This mechanism allows URI- 
list servers to send the same recipient-history list to each 
recipient of the SIP request. However, recipients who are tagged 


with "bcc" values are not explicitly informed about it. 


o URI-list servers MUST preserve with a "bcc" copy control in the 
recipient-history list the URI that identifies the recipient (if 
any) and MUST remove the remaining URIs marked with a "bcc" copy 
control. Consequently, each recipient receives a different 
recipient-history list. However, recipients who have been marked 
with a "bcc" copy control are explicitly informed about it. 


Implementations that are able to receive recipient-history lists must 
pay attention to the contents of the list. If the recipient’s URI is 
not included in the recipient-history list or if it is included but 
tagged with a "bcc" copy control, then implementations SHOULD prevent 
the user from replying to all the recipients of the SIP request. 

This would allow the non-blind recipients to notice the existence of 
blind recipients of the SIP request. 
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A new ’anonymize’ attribute can be included in a <entry> element of 
the resource list document format [RFC4826]. If set to a "true" 
value, it provides an indication to the URI-list server for not 
disclosing the URI itself in a URI list sent to the recipient, but 
instead to anonymize the URI (i.e., making it bogus in the recipient- 
history XML resource list). URI-list servers can use URIs tagged 
with the ’anonymize’ attribute for routing SIP requests, but MUST 
convert them to the SIP URI "sip:anonymous@anonymous.invalid" in 
recipient-history lists. The default value of the ’anonymize’ 
attribute is "false". 


There are occasions where the URI-list server encounters the same URI 
entry duplicated in a resource list, where duplicated URI entries are 
tagged with the same or different values of the ’copyControl’ 
attribute. There are no reasonable usages that justify duplicated 
URIs in resource lists; thus, this is considered an error. URI-list 
servers should not send duplicated copies of the same SIP request to 
the same intended recipient. In case the URI-list server encounters 
the same URI entry duplicated in a resource list, it should send at 
most a single copy of the request to that intended recipient. For 
each set of duplicated URI entries, the URI-list server MUST select 
the highest precedence value of the 'copyControl” attribute for the 
same intended recipient. The order of precedence of the values of 
the ’copyControl’ attribute is: "to", "cc", and "bcc". Once the URI- 
list server has selected a value for the 'copyControl” attribute of 
an intended recipient, the URI-list server can continue processing 
the request. 


Processing of URIs tagged with a ’copyControl’ attribute set toa 
"bcc" value has higher precedence over the 'anonymize” attribute. 
Thus, if the ’copyControl’ of a URI is set to "bcc", the URI-list 
server MUST remove that URI from the recipient-history list, and the 
‘anonymize’ attribute will be ignored. Therefore, the ’anonymize’ 
attribute is only useful for those URIs tagged with a ’copyControl’ 
of "to" or "cc". 


A new ’count’ attribute can be also included in an <entry> element of 
the resource list document format [RFC4826]. It provides the number 
of equal URIs. Typically, recipient lists created by UACs will not 
have equal (or duplicate) URI entries; thus, it is not expected to 
contain URIs tagged with ’count’ attributes. However, recipient- 
history lists can contain duplicated anonymized URIs; therefore, it 
is expected that recipient-history lists will contain ’count’ 
attributes. The default value of the ‘count’ attribute is "1". 
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The ’copyControl’, 'anonymize”, and ‘count’ attributes SHOULD be 
included as modifiers of any of the child elements included in the 
<list> element of a resource list (e.g., attribute of the <entry> or 
<external> elements). 


Section 5 describes the format of the ’copyControl’, ’anonymize’, and 
‘count’ attributes. Implementations according to this specification 
MUST support this XML schema. 


Implementations that receive recipient-history lists must pay 
attention to the contents of the list. If the recipient’s URI is not 
included in recipient-history list or if it is included but tagged 
with a "bcc" copy control, then they SHOULD prevent the user from 
replying to all the recipients of the SIP request. This would allow 
the non-blind recipients to notice the existence of blind recipients 
in the original SIP request. 


5. XML Schema 


<?xml version="1.0" encoding="UTF-8"?> 

<xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol" 
xmlns="urn:ietf:params:xml:ns:copycontrol" 
xmlns:rls="urn:ietf:params:xml:ns:resource-lists" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<xs:annotation> 
<xs:documentation xml:lang="en"> 
Adds the copyControl, anonymize, and count attributes 
to URIs included in a resource list. 
</xs:documentation> 
</xs:annotation> 


<xs: import namespace="urn:ietf:params:xml:ns:resource-lists" 
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/> 


<xs:attribute name="copyControl"> 
<xs:simpleType> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="to"/> 
<xs:enumeration value="cc"/> 
<xs:enumeration value="bcc"/> 
</xs:restriction> 
</xs:simpleType> 
</xs:attribute> 
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<xs:attribute name="anonymize" type="xs:boolean" default="false"/> 
<xs:attribute name="count" type="xs:nonNegativelnteger" 
default="1"/> 


</xs:schema> 
Figure 2: XML schema of the extension to the resource list format 
6. Examples 


This section shows two examples of URI lists that can be included in 
SIP requests. The first example in Figure 3 shows a recipient list 
that the UAC sends to the URI-list server. This corresponds to a 
list that will be included in the flow F2 in Figure 1. The recipient 
list contains a flat list according to the resource list data format 
specified in RFC 4826 [RFC4826]. Each resource indicates the copy 
control of a resource with a ’copyControl’ attribute. Some of the 
resources are also marked with the ’anonymize’ attribute. This 
provides an indication to the URI-list service for not disclosing 
their URIs in a recipient-history list. The last two <entry> 
elements are marked with a ’copyControl’ attribute of "bcc". This 
provides an indication to the URI-list server for removing these URIs 
in the recipient-history list. 


<?xml version="1.0" encoding="UTF-8"?> 
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" 
xmlns:cp="urn:ietf:params:xml:ns:copycontrol"> 
<list> 
<entry uri="sip:billftexample.com" cp:copyControl="to" /> 
<entry uri="sip:randylexample.net" cp:copyControl="to" 
cp:anonymize="true"/> 
<entry uri="sip:eddy@example.com" cp:copyControl="to" 
cp:anonymize="true"/> 
<entry uri="sip: joe@example.org" cp:copyControl="cc" /> 
<entry uri="sip:carol@example.net" cp:copyControl="cc" 
cp:anonymize="true"/> 
<entry uri="sip:ted@example.net" cp:copyControl="bcc" /> 
<entry uri="sip:andy@example.com" cp:copyControl="bcc" /> 
</list> 
</resource-lists> 


Figure 3: Recipient list sent from the UAC to the URI-list server 


Upon receipt of the SIP request containing the recipient list of 
Figure 3, the URI-list server creates a SIP request to each of the 
URIs listed in the recipient list (so, in our example, it creates 7 
SIP requests). The URI-list server processes the recipient list and 
creates a recipient-history list that is included in each of the 


Garcia-Martin € Camarillo Standards Track [Page 9] 


RFC 5364 Copy Control Attribute in Resource Lists October 2008 


outgoing SIP requests. The process is as follows: the URI-list 
server creates a new recipient-history list, based on the recipient 
list, but with changes. First, it copies all the URIs (<entry> 
elements) marked with the "to" or "cc" ’copyControl’ attributes, 
which do not contain an ’anonymize’ attribute (or when the 
‘anonymize’ attribute is set to "false"). Then all the URIs marked 
with a 'copyControl” attribute set to "to" and 'anonymize” attribute 
set to "true" are replaced with the SIP anonymous URI 
"sip:anonymous@anonymous.invalid". In this entry, the URI-list 
server also adds the original value of the ’copyControl’ attribute 
("to" in our example), and it adds a 'count” attribute containing the 
number of anonymous entries in this group ("2" in our example). Then 
the URI-list server does the same operation to the URIs tagged with 
the ‘’copyControl’ attribute set to "cc" and ’anonymize’ attribute set 
to "true", adding also the ’count’ attribute containing the number of 
anonymous attributes in this group ("1" in the example). Last, the 
URI-list server removes all URIs marked with the "bcc" 'copyControl” 
attribute. The resulting recipient-history list is shown in 

Figure 4. 


<?xml version="1.0" encoding="UTF-8"?> 
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" 
xmlns:cp="urn:ietf:params:xml:ns:copycontrol"> 
<list> 
<entry uri="sip:bill@example.com" cp:copyControl="to" /> 
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to" 
cp:count="2"/> 
<entry uri="sip:joe@example.org" cp:copyControl="cc" /> 
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" 
cp:count="1"/> 
</list> 
</resource-lists> 


Figure 4: Recipient-history list sent from the URI-list server to 
each recipient 


7. Carrying URI Lists in SIP 


A SIP UAC (User Agent Client) that composes a SIP request can include 
a URI list with the extensions specified in this document to indicate 
the list of intended recipients. On doing so, as specified in RFC 
5363 [RFC5363], the UAC adds a Content-Disposition [RFC2183] header 
field set to the value 'recipient-list'. Typically UACs send these 
‘recipient-list’ bodies to URI-list services (this corresponds to 
flow Fl in Figure 1). A body whose Content-Disposition type is 
‘recipient-list’ contains a URI list that includes the intended 
recipients of the SIP request, something known throughout this 
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document as a recipient list. The <entry> element in the URI list 
MAY also include a 'copyControl” and ’anonymize’ attributes, as 
specified in Section 4. 


To be able to inform intended recipients of who else is receiving a 
copy of the SIP request, we define a new mail disposition type to be 
included in a Content-Disposition [RFC2183] header field of a SIP 
request. The value of this new disposition type is 'recipient-list- 
history’ and its purpose is to indicate a list of recipients that a 
SIP request was sent to, something known throughout this document as 
a recipient-history list. A body whose Content-Disposition type is 
"recipient-list-history” contains a URI list with the visible 
(including anonymized) recipients of the SIP request. The <entry> 
element in the URI list MAY also include a 'copyControl” and ‘count’ 
attributes, as specified in Section 4. 


On sending a SIP request that contains a recipient-history list, if 
the intended recipient does not support this specification, the SIP 
request should not fail. In order to ensure successful receipt of 
the SIP requests that include 'recipient-list-history” bodies, User 
Agents (such as URI-list servers) that build SIP requests with the 
Content-Disposition header field set to 'recipient-list-history' 
SHOULD add a "handling" parameter [RFC3204] set to "optional". 
Otherwise, the SIP request could fail and never be received by the 
intended recipient. 


Even though "Message Body Handling in SIP" [SIP_BODY] mandates 
support for multipart bodies, legacy recipients may not support them. 
In such a case, if the request sent by the relay to the recipient 
needs to contain another body (e.g., a MESSAGE request carrying a 
message in its body), the relay will not be able to use this 
extension because the recipient would not be able to process a 
multipart body with the original body plus the 'recipient-list- 
history” body. 


8. Security Considerations 
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. 
Implementations of this specification MUST follow the security- 
related rules in RFC 5363 [RFC5363]. These rules include opt-in 


lists and mandatory authentication and authorization of clients. 


User Agent Clients SHOULD NOT hand SIP requests containing URI-list 


services to unauthenticated and untrusted parties. This is to avoid 
man-in-the-middle attacks or acquiring URI lists for performing spam 
attacks. 
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URI lists may contain private information, such as SIP URIs. It is 
therefore not desirable that these URI lists are known by third 
parties. Eavesdroppers are able to watch URI lists contained in SIP 
requests unless the SIP message is sent over a secured channel, by 
using any of the available SIP mechanisms, such as Transport Layer 
Security (TLS) [RFC4346], or unless the URI-list body itself is 
encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED 
that URI-list bodies are encrypted with S/MIME [RFC3851] or that the 
SIP request is encrypted with TLS [RFC4346] or any other suitable 
encryption mechanism. 


Note that this URI list does not indicate the actual participants in 
the session. It indicates only the URIs invited and that might 
accept the request. It does not assert that these parties actually 
exist, that they are reachable at the given URI, or that they have 
accepted the invitation. No inferences about billing should be made 
from this information. It is subject to spoofing by loading the list 
with falsified content. 


Issuers of SIP request use the "bcc" copy control attribute described 
in Section 4 to facilitate sending SIP requests to recipients without 
revealing the URIs of one or more of the other recipients. 
Mishandling this use of "bcc" copy control has implications for 
confidential information that might be revealed, which could 
eventually lead to security problems through knowledge of even the 
existence of a particular URI. For example, if using the first 
method described in Section 4, where the "bcc" tagged URIs are 
removed from the recipient-history list, blind recipients have no 
explicit indication that they have been sent a blind copy of the SIP 
request, except insofar as their URI does not appear in the 
recipient-history list. Because of this, one of the blind URIs could 
potentially send a reply to all of the shown recipients and 
accidentally reveal that the message went to the blind recipient. 
When the second method from Section 4 is used, the blind recipient’s 
address appears in the recipient-history list of a separate copy of 
the list. If the "bcc" tagged URI sent contains all of the "bcc" 
tagged URIs, all of the "bcc" recipients will be seen by each "bcc" 
recipient. Even if a separate message is sent to each "bcc" 
recipient with only the individual’s URI, implementations still need 
to be careful to process replies to the message as per Section 4 so 
as not to accidentally reveal the blind recipient to other 
recipients. 
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9. IANA Considerations 


IANA has made registrations according to the following subsections: a 
new disposition type, a new XML namespace, and a new XML schema. 


9.1. Disposition Type Registration 


Section 7 defines a new 'recipient-list-history” value of the Mail 
Content Disposition Values registry. This value has been registered 
in the IANA registry of Mail Content Disposition Values with the 
following registration data: 


+------------------------ +------------------------------ +----------- + 
| Name | Description | Reference | 
$ +------------------------------ +----------- + 
recipient-list-history the body contains a list of [RFC5364] 
URIs that indicates the 
| | recipients of the request | 
+------------------------ +------------------------------ +----------- + 


Table 1: Registration of the 'recipient-list-history” Mail Content 
Disposition Value 


9.2. XML Namespace Registration 


This section registers a new XML namespace in the IANA XML registry, 
as per the guidelines in RFC 3688 [RFC3688]. 


URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol 


Registrant Contact: IETF SIPPING working group (sipping@ietf.org), 
Miguel Garcia-Martin (miguel.a.garcia@ericsson.com). 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basicl0.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtm1"> 
<head> 
<meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1"/> 
<title>Copy Control Namespace</title> 
</head> 
<body> 
<hl>Namespace for the Copy Control Attribute Extension 
in Resource Lists</hl1> 
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<h2>urn:ietf:params:xml:ns:copycontrol</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt"> 
RFC5364</a>.</p> 
</body> 
</html> 
END 


9.3. XML Schema Registration 


This section registers a new XML schema in the IANA XML registry per 
the procedures in RFC 3688 [RFC3688]. 


URI: urn:ietf:params:xml:schema:copycontrol 


Registrant Contact: IETF SIPPING working group (sipping@ietf.org), 
Miguel Garcia-Martin (miguel.a.garcia@ericsson.com). 


The XML for this schema can be found as the sole content of 
Section 5. 
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